Code Injection Attacks on Harvard-Architecture Devices 



Aurelien Francillon 
INRIA Rhone-Alpes 
655 avenue de I'Europe, Montbonnot 
38334 Saint Ismier Cedex, France 
aurelien.francillon@inria.fr 



Claude Castelluccia 

INRIA Rhone-Alpes 
655 avenue de I'Europe, Montbonnot 
38334 Saint Ismier Cedex, France 

claude.castelluccia@inria.fr 



On 
O 
O 
(N 

(N 



u 

o 



> 

(N 
00 

rn 

o 

On 
O 



X 



ABSTRACT 

Harvard architecture CPU design is common in the embed- 
ded world. Examples of Harvard-based architecture devices 
are the Mica family of wireless sensors. Mica motes have 
limited memory and can process only very small packets. 
Stack-based buffer overflow techniques that inject code into 
the stack and then execute it are therefore not applicable. It 
has been a common belief that code injection is impossible 
on Harvard architectures. This paper presents a remote code 
injection attack for Mica sensors. We show how to exploit 
program vulnerabilities to permanently inject any piece of 
code into the program memory of an Atmel AVR-based sen- 
sor. To our knowledge, this is the first result that presents 
a code injection technique for such devices. Previous work 
only succeeded in injecting data or performing transient at- 
tacks. Injecting permanent code is more powerful since the 
attacker can gain full control of the target sensor. We also 
show that this attack can be used to inject a worm that can 
propagate through the wireless sensor network and possibly 
create a sensor botnet. Our attack combines different tech- 
niques such as return oriented programming and fake stack 
injection. We present implementation details and suggest 
some counter-measures. 



Categories and Subject Descriptors 

D.4.6 [Operating Systems]: Security and Protection 

General Terms 

Experimentation, Security 

Keywords 

Harvard Architecture, Embedded Devices, Wireless Sensor 
Networks, Code Injection Attacks, Gadgets, Return Ori- 
ented Programming, Buffer Overflow, Computer Worms 



Permission to make digital or hard copies of all or part of this work for 
personal or classroom use is granted without fee provided that copies are 
not made or distributed for profit or commercial advantage and that copies 
bear this notice and the full citation on the first page. To copy otherwise, to 
republish, to post on servers or to redistribute to lists, requires prior specific 
permission and/or a fee. 

CCS'08, October 27-31, 2008, Alexandria, Virginia, USA. 
Copyright 2008 ACM 978-1-59593-810-7/08/10 ...$5.00. 



1. INTRODUCTION 

Worm attacks exploiting memory-related vulnerabilities 
are very common on the Internet. They are often used to 
create botnets, by compromising and gaining control of a 
large number of hosts. 

It is widely believed that these types of attacks are diffi- 
cult, if not impossible, to perform on Wireless Sensor Net- 
works (WSN) that use Mica motes [2T1 [TT]. For example, 
Mica sensors use a Harvard architecture, that physically 
separates data and program memories. Standard memory- 
related attacks [I] that execute code injected in the stack 
are therefore impossible. 

As opposed to sensor network defense (code attestation, 
detection of malware infections, intrusion detection [221 14]) 
that has been a very active area of research, there has been 
very little research on node-compromising techniques. The 
only previous work in this area either focused on Von Neu- 
mann architecture-based sensors [TO] or only succeeded to 
perform transient attacks that can only execute sequences 
of instructions already present in the sensor program mem- 
ory |12] , Permanent code injection attacks are much more 
powerful: an attacker can inject malicious code in order to 
take full control of a node, change and/or disclose its security 
parameters. As a result, an attacker can hijack a network 
or monitor it. As such, they create a real threat, especially 
if the attacked WSN is connected to the Internet |20| . 

This paper presents the design of the first worm for Har- 
vard architecture-based WSNs. We show how to inject arbi- 
trary malware into a sensor. This malware can be converted 
into a worm by including a self-propagating module. Our 
attack combines several techniques. Several special packets 
are sent to inject a fake stack in the victim's data memory. 
This fake stack is injected using sequences of instructions, 
called gadgets [23], already present in the sensor's program 
memory. Once the fake stack is injected another specially- 
crafted packet is sent to execute the final gadget chain. This 
gadget uses the fake stack and copies the malware (contained 
in the fake stack) from data memory to program memory. 
Finally, the malware is executed. The malware is injected in 
program memory. It is therefore persistent, i.e., it remains 
even if the node is reset. 

Our attack was implemented and tested on Micaz sen- 
sors. We present implementation details and explain how 
this type of attacks can be prevented. 

The paper is structured as follows: Section [5] introduces 
the platform hardware and software. The major difficulties 
to overcome are detailed in Section [3] Section f3] presents 
the related work. Section [5] gives an overview of the attack, 



whose details are provided in Section[6] Protection measures 
are introduced in Section [7] Finally, Section [8] concludes the 
paper and presents some future work. 

2. ATMEL AVR-BASED SENSOR 
ARCHITECTURE OVERVIEW 

The platform targeted in this attack is the Micaz motes [7]. 
It is one of the most common platform for WSNs. Micaz is 
based on an Atmel AVR Atmega 128 8-bit microcontroller [3] 
clocked at a frequency of 8MHz and an IEEE 802.15.4 [TS] 
compatible radio. 

2.1 The AVR architecture 

The Atmel Atmega 128 3 is a Harvard architecture mi- 
crocontroller. In such microcontrollers, program and data 
memories are physically separated. The CPU can load in- 
structions only from program memory and can only write 
in data memory. Furthermore, the program counter can 
only access program memory. As a result, data memory can 
not be executed. A true Harvard architecture completely 
prevents remote modification of program memory. Modifi- 
cation requires physical access to the memory. As this is 
impractical, true Harvard-based microcontrollers are rarely 
used in practice. Most of Harvard-based microcontrollers 
are actually using a modified Harvard architecture. In such 
architecture, the program can be modified under some par- 
ticular circumstances. 

For example, the AVR assembly language has dedicated 
instructions ( "Load from Program Memory" (LPM) and 
"Store to Program Memory" (SPM) ) to copy bytes from/to 
program memory to/from data memory. These instructions 
are only operational from the bootloader code section (see 
Section ^. 3|l . They are used to load initialisation values from 
program memory to data section, and to store large static ar- 
rays (such as key material or precomputed table) in program 
memory, without wasting precious SRAM memory. Further- 
more, as shown in Section l2~3l the SPM instruction is used to 
remotely configure the Micaz node with a new application. 

2.2 The memories 

As shown on Figure [T (a) | the Atmega 128 microcontroller 
has three internal memories, one external memory, and a 
flash chip, on the Micaz board. 

• The internal flash (or program memory), is where pro- 
gram instructions are stored. The microprocessor can 
only execute code from this area. As most instruc- 
tions are two bytes or four bytes long, program mem- 
ory is addressed as two-byte words, i.e., 128 KBytes of 
program memory are addressable. The internal flash 
memory is usually split into two main sections: ap- 
plication and bootloader sections. This flash memory 
can be programmed either by a physical connection 
to the microcontroller or by self-reprogramming. Self- 
reprogramming is only possible from the bootloader 
section. Further details on the bootloader and self- 
reprogramming can be found in Section \2. 31 

• Data memory address space is addressable with regu- 
lar instructions. It is used for different purposes. As 
illustrated in Figure [T (b) | it contains the registers, the 
Input Output area, where peripherals and control reg- 
isters are mapped, and 4 KBytes of physical SRAM. 



Since the microcontroller does not use any Memory 
Management Unit (MMU), no address verification is 
performed before a memory access. As a result, the 
whole data address space (including registers and I/O) 
are directly addressable. 

The EEPROM memory is mapped to its own address 
space and can be accessed via the dedicated IO regis- 
ters. It therefore can not be used as a regular memory. 
Since this memory area is not erased during repro- 
gramming or power cycling of the CPU, it is mostly 
used for permanent configuration data. 

The Micaz platform has an external flash memory which 
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(b) Typical memory organisation on an Atmel Atmega 128. 
Program memory addresses are addressed either as 16bit 
words or as bytes depending on the context. 

Figure Is Memory organisation on a Micaz. 



is used for persistent data storage. This memory is ac- 
cessed as an external device from a serial bus. It is not 
accessible as a regular memory and is typically used to 
store sensed data or program images. 

2.3 The bootloader 

A sensor node is typically configured with a monolithic 
piece of code before deployment. This code implements the 
actions that the sensor is required to perform (for example, 
collecting and aggregating data). However, there are many 
situations where this code needs to be updated or changed 
after deployment. For example, a node can have several 
modes of operation and switch from one to another. The size 
of program memory being limited, it is often impossible to 
store all program images in program memory. Furthermore, 
if a software bug or vulnerability is found, a code update is 
required. If a node cannot be reprogrammed, it becomes un- 
usable. Since it is highly impractical (and often impossible) 
to collect all deployed nodes and physically reprogram them, 
a code update mechanism is provided by most applications. 
We argue that such a mechanism is a strong requirement 
for the reliably and survivability of a large WSN. On an 
Atmegal28 node, the reprogramming task is performed by 
the bootloader, which is a piece of code that, upon a remote 
request, can change the program image being ran on a node. 

External flash memory is often used to store several pro- 
gram images. When the application is solicited to reprogram 
a node with a given image, it configures the EEPROM with 
the image identifier and reboots the sensor. The bootloader 
then copies the requested image from external flash mem- 
ory to program memory. The node then boots on the new 
program image. 

On a Micaz node, the bootloader copies the selected im- 
age from external flash memory to the RAM memory in 256- 
byte pages. It then copies these pages to program memory 
using the dedicated SPM instruction. Note that only the 
bootloader can use the SPM instruction to copy pages to 
program memory. Different images can be configured stat- 
ically, i.e., before deployment, to store several program im- 
ages. Alternatively, these images can be uploaded remotely 
using a code update protocol such as TinyOS's Deluge [14] . 

In the rest of this paper, we assume that each node is 
configured with a bootloader. We argue that this is a very 
realistic assumption since, as discussed previously, a wireless 
sensor network without self-reprogramming capability would 
have limited value. We do not require the presence of any 
remote code update protocols, such as Deluge. However, 
if such a protocol is available, we assume that it is secure, 
i.e., the updated images are authenticated [5] [T7] [T5] IT5] . 
Otherwise, the code update mechanism could be trivially 
exploited by an attacker to perform code injection. 

3. ON THE DIFFICULTY OF EXPLOITING 
A SENSOR NODE 

Traditional buffer overflow attacks usually rely on the fact 
that the attacker is able to inject a piece of code into the 
stack and execute it. This exploit can, for example, result 
from a program vulnerability. 

In the Von Neumann architecture, a program can access 
both code (TEXT) and data sections (data, BSS or Stack). 
Furthermore, instructions injected into data memory (such 
as stack) can be executed. As a result, an attacker can 



exploit buffer overflow to execute malicious code injected by 
a specially-crafted packet. 

In Mica-family sensors, code and data memories are phys- 
ically separated. The program counter cannot point to an 
address in the data memory. The previously presented in- 
jection attacks are therefore impossible to perform on this 
type of sensor |21l 111] , 

Furthermore, sensors have other characteristics that limit 
the capabilities of an attacker. For example, packets pro- 
cessed by a sensor are usually very small. For example 
TinyOS limits the size of packet's payload to 28 bytes. It 
is therefore difficult to inject a useful piece of code with a 
single packet. Finally, a sensor has very limited memory. 
The application code is therefore often size-optimized and 
has limited functionality. Functions are very often inlined. 
This makes "return-into-libc" attacks [25] very difficult to 
perform. 

Because of all these characteristics, remote exploitation of 
sensors is very challenging. 

4. RELATED WORK 

4.1 From "return-into-libc" attack to gadgets 

In order to prevent buffer overflow exploitation in general 
purpose computers, memory protection mechanisms, known 
as the no-execute bit (NX-Bit) or Write-Xor-Execute(VK g) 
E) [2j [8] 1271 121] have been proposed. These techniques en- 
force memory to be either writable or executable. Trying 
to execute instructions in a page marked as non executable 
generates a segmentation fault. The main goal of these tech- 
niques is to prevent execution of code in the stack or more 
generally in data memory. The resulting protection is simi- 
lar to what is provided by Harvard architectures. 

Several techniques have been developed to bypass these 
protection mechanisms. The first published technique was 
the "return-into-libc" attack [25] where the attacker does 
not inject code to the stack anymore but instead executes a 
function of the libc. The "return-into-libc" attack has been 
extended into different variants. |23] generalizes this tech- 
nique and shows that it is possible to attack systems which 
are running under W ® E like environments by executing se- 
quences of instructions terminated by a "ret". These groups 
of instructions are called Gadgets. Gadgets are performing 
actions useful to the attacker (i.e., pop a value in stack to a 
register) and possibly returning to another gadget. 

4.2 Exploitation of sensor nodes 

Stack execution on Von Neumann architecture sensors. 

[101 111] show how to overcome the packet size limitation. 
The author describes how to abuse string format vulnerabil- 
ities or buffer overflows on the MSP430 based Telosb motes 
in order to execute malicious code uploaded into data mem- 
ory. He demonstrates that it is possible to inject malicious 
code byte-by-byte in order to load arbitrary long bytecode. 
As Telosb motes are based on the MSP430 microcontroller 
(a Von Neumann architecture), it is possible to execute ma- 
licious data injected into memory. However, as discussed in 
Section 12.11 this attack is impossible on Harvard architec- 
ture motes, such as the Micaz. Countermeasures proposed 
in QT] include hardware modifications to the MSP430 micro- 
controller and using Harvard architecture microcontrollers. 



The hardware modification would provide the ability to con- 
figure memory regions as non executable. In our work, we 
show by a practical example that, although this solution 
complicates the attack, it does not make it impossible. 

Mal-Packets. 

[12] shows how to modify the execution flow of a TinyOS 
application running on a Mica2 sensor (a Micaz with a differ- 
ent radio device) to perform a transient attack. This attack 
exploits buffer overflow in order to execute gadgets, i.e., in- 
structions that are present on the sensor. These instructions 
perform some actions (such as possibly modifying some of 
the sensor data) and then propagate the injected packet to 
the node's neighbors. 

While this attack is interesting, it has several limitations. 
First, it is limited to one packet. Since packets are very 
small, the possible set of actions is very limited. Second, 
actions are limited to sequences of instructions present in 
the sensor memory. Third, the attack is transient. Once the 
packet is processed, the attack terminates. Furthermore, the 
action of the attack disappears if the node is reset. 

In contrast, our attack allows injection of any malicious 
code. It is therefore much more flexible and powerful. Note 
that our scheme also makes use of gadgets. However, gadgets 
are used to implement the function that copies injected code 
from data memory to program memory. It is not used, as 
in the Mal-Packets scheme, to execute the actual malicious 
actions. Therefore, our requirement (in terms of instruc- 
tions present in the attacked node) is much less stringent. 
Furthermore, in our scheme, the injected code is persistent. 

5. ATTACK OVERVIEW 

This section describes the code injection attack. We first 
describe our system assumptions and present the concept 
of a meta-gadget, a key component of our attack. We then 
provide an overview of the proposed attack. Implementation 
details are presented in the next section. 

5.1 System assumptions 

Throughout this paper, we make the following assump- 
tions: 

• The WSN under attack is composed of Micaz nodes [7]- 

• All nodes are identical and run the same code. 

• The attacker knows the program memory content . 

• Each node is running the same version of TinyOS and 
no changes were performed in the OS libraries. 

• Each node is configured with a bootloader. 

• Running code has at least one exploitable buffer over- 
flow vulnerability. 

5.2 Meta-gadgets 

As discussed in Section [3] it is very difficult for a remote 
attacker to directly inject a piece of code on a Harvard-based 
sensor. However, as described in [23], an attacker can exploit 
a program vulnerability to execute a gadget, i.e. a sequence 
of instructions already in program memory that terminates 



with a ret. Provided that it injects the right parameters 
into the stack, this attack can be quite harmful. The set of 
instructions that an attacker can execute is limited to the 
gadgets present in program memory. In order to execute 
more elaborate actions, an attacker can chain several gadgets 
to create what we refer to as meta-gadget in the rest of this 
paper. 

In [23], the authors show that, on a regular computer, an 
attacker controlling the stack can chain gadgets to undertake 
any arbitrary computation. This is the foundation of what 
is called return-oriented programming. On a sensor, the ap- 
plication program is much smaller and is usually limited to 
a few kilobytes. It is therefore questionable whether this 
result holds. However, our attack does not require a Turing 
complete set of gadgets. In fact, as shown in the rest of this 
section, we do not directly use this technique to execute ma- 
licious code as in [23] ■ Instead, we use meta-gadgets to inject 



event message_t* 

H,eceive.receWe(message_t* bufPtr, void* payload, 
uint8_t len){ 
// BUFFJLEN is defined somewhere else as 4 
»m«J tmp_buff[BUFF_LEN]; 
rem = (radio_couni^msg_t*)pa.yload; 

II copy the content in a buffer for further processing 
for (i=0;i<rcm— >buff_len; i++){ 

tmp_buff[i]=rcm— >buff[i]; // vulnerability 

} 

return bufPtr; 

} 



(a) Sample buffer management vulnerability. 



uint8-t payload [ ]={ 




0x00,0x01,0x02,0x03, // padding 


0x58,0x2b, 


// Address of gadget 1 


ADDRJL,ADDR_H, // address to write 


0x00, 


// Padding 


DATA, 


// data to write 


0x00,0x00,0x00, 


// padding 


0x85,0x01, 


// address of gadget 2 


0x3a,0x07, 


// address of gadget 3 


0x00.0x00 

}; 


// Soft reboot address 



(b) Payload of the injection packet 
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(c) Buffer overfl ow w ith a packet containing the bytes 
shown in Figure 2(b) 



1 It has, for example, captured a node and analysed its binary 
code. 



Figure 2: Vulnerability exploitation. 



malicious code into the sensor. The malicious code, once in- 
jected, is then executed as a "regular" program. Therefore, 
as shown below, the requirement on the present code is less 
stringent. Only a limited set of gadgets is necessary. 

5.3 Incremental attack description 

The ultimate goal of our attack is to remotely inject a 
piece of (malicious) code into a sensor's flash memory. We 
first describe the attack by assuming that the attacker can 
send very large packets. We then explain how this injection 
can be performed with very small packets. This section pro- 
vides a high-level description. The details are presented in 
Section [6] 

5.3.1 Injecting code into a Harvard-based sensor 
without packet size limitation 

As discussed previously, most sensors contain bootloader 
code used to install a given image into program memory 
(see Section T2.3p . It uses a function that copies a page from 
data memory to program memory. One solution could be 
to invoke this function with the appropriate arguments to 
copy the injected code into program memory. However, the 
bootloader code is deeply inlined. It is therefore impossible 
to invoke the desired function alone. 

We therefore designed a " Reprogramming" meta-gadget, 
composed of a chain of gadgets. Each gadget uses a sequence 
of instructions from bootloader code and several variables 
that are popped from the stack. To become operational, 
this meta-gadget must be used together with a specially- 
crafted stack, referred to as the fake stack in the rest of this 
section. This fake stack contains the gadget variables (such 
as ADDRm; the address in the program memory where to 
copy the code), addresses of gadgets and code to be injected 
into the node. Details of this meta-gadget and the required 
stack are provided later in Section [6] 

5.3.2 Injecting code into a Harvard-based sensor with 
small packets 

The attack assumes that the adversary can inject arbitrar- 
ily large data into the sensor data memory. However, since 
the maximum packet size is 28 bytes, the previous attack 
is impractical. To overcome this limitation, we inject the 
fake stack into the unused part of data memory (see Fig- 
ure 1(b) I byte- by- byte and then invoke the Reprogramming 



meta-gadget, described in the previous section, to copy the 
malware in program memory. 

In order to achieve this goal, we designed an "Injection" 
meta-gadget that injects one byte from the stack to a given 
address in data memory. This Injection meta-gadget is de- 
scribed in Section \6. 31 

The overview of the attack is as follows: 

1. The attacker builds the fake stack containing the ma- 
licious code to be injected into data memory. 

2. It then sends to the node a specially-crafted packet 
that overwrites the return address saved on the stack 
with the address of the Injection meta-gadget. This 
meta-gadget copies the first byte of the fake stack (that 
was injected into the stack) to a given address A (also 
retrieved from the stack) in data memory. The meta- 
gadget ends with a ret instruction, which fetches the 
return address from the fake stack. This value is set 



to 0. As a result, the sensor reboots and returns to a 
"clean state". 

3. The attacker then sends a second specially-crafted pa- 
cket that injects the second byte of the fake stack at 
address A + 1 and reboots the sensor. 

4. Steps 2 and 3 are repeated as necessary. After n pack- 
ets, where n is the size of the fake stack, the whole 
fake stack is injected into the sensor data memory at 
address A. 

5. The attacker then sends another specially-crafted pa- 
cket to invoke the Reprogramming meta-gadget. This 
meta-gadget copies the malware (contained into the in- 
jected fake stack) into program memory and executes 
it, as described in Section [5.3.1 1 

5.3.3 Memory persistence across reboots 

Once a buffer overflow occurs, it is difficult |12| . and some- 
times impossible, to restore consistent state and program 
flow. Inconsistent state can have disastrous effects on the 
node. In order to re-establish consistent state, we reboot 
the attacked sensor after each attack. We perform a "soft- 
ware reboot" by simply returning to the reboot vector (at 
address 0x0). During a software reboot, the init functions 
inserted by the compiler/libc initializes the variables in data 
section. It also initializes the BSS section to zero. All other 
memory areas (in SRAM) are not modified. For example, 



the whole memory area (marked as "unused" in Figure 1(b) \ 



which is located above the BSS section and below the max 
value of the stack pointer, is unaffected by reboots and the 
running application. 

This memory zone is therefore the perfect place to inject 
hidden data. We use it to store the fake stack byte-by- 
byte. This technique of recovering bytes across reboots is 
somewhat similar to the attack on disk encryption, presented 
in [T5], which recovers the data in a laptop's memory after 
a reboot. However, one major difference is that, in our case, 
the memory is kept powered and, therefore, no bits are lost. 

6. IMPLEMENTATION DETAILS 

This section illustrates the injection attack by a simple 
example. We assume that the node is running a program 
that has a vulnerability in its packet reception routine as 
shown in Figure [2(a) | The attacker's goal is to exploit this 
vulnerability to inject malicious code. 

This section starts by explaining how the vulnerability is 
exploited. We then describe the implementation of the In- 
jection and Reprogramming meta-gadgets that are needed 
for this attack. We detail the structure of the required fake 
stack, and how it is injected byte-by-byte into data memory 
with the Injection meta-gadget. Finally, we explain how the 
Reprogramming meta-gadget uses the fake stack to repro- 
gram the sensor with the injected malware. 

6.1 Buffer overflow exploitation 

The first step is to exploit a vulnerability in order to take 
control of the program flow. In our experimental example, 
we use standard buffer overflow. We assume that the sensor 
is using a packet reception function that has a vulnerabil- 
ity (see Figure [2(a)[ |. This function copies into the array 
tmp_buff of size BUFF_LEN, rcm->buf f er_len bytes of ar- 
ray rcm->buff , which is one of the function parameters. If 
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(b) Real Injection meta-gadget. 



Figure 3: Injection meta-gadget. 



rcm->buf f er_len is set to a value larger than BUFF_LEN, a 
buffer overflow occurs 2 . This vulnerability can be exploited 
to inject data into the stack and execute a gadget as illus- 
trated below. During a normal call of the receive function, 
the stack layout is displayed in Figure 2(c) and is used as 
follows: 



Before the function receive is invoked the stack pointer 
is at address 0x1060. 

When the function is invoked the call instruction stores 
the address of the following instruction (i.e. the in- 



2 This hypothetical vulnerability is a quite plausible flaw - 
some have been recently found and fixed in Tiny OS see [5] 



struction following the call instruction) into the stack. 
In this example we refer to this address as @ret (@retH 
and @retL being respectively the MSB and the LSB 
bytes) . 

• Once the call instruction is executed, the program 
counter is set to the beginning of the called function, 
i.e., the receive function. This function is then in- 
voked. It possibly saves, in its preamble, the registers 
on the stack (omitted here for clarity), and allocates 
its local variables on the stack, i.e. the 4 bytes of the 
tmp_buf f array (the stack pointer is decreased by 4). 

• The for loop then copies the received bytes in the 
tmp_buf f buffer that starts at address 0x1 05B. 

• When the function terminates, the function deallocates 
its local variables (i.e. increases the stack pointer), 
possibly restores the registers with pop instructions, 
and executes the ret instruction, which reads the ad- 
dress to return to from the top of the stack. If an 
attacker sends a packet formatted as shown in Fig- 
ure 2(b) the data copy operation overflows the 4- bytes 
buffer with 19-bytes. As a result, the return address 
is overwritten with the address 0x2b58 and 13 more 
bytes (used as parameters by the gadget) are written 
into the stack. The ret instruction then fetches the 
return address 0x2b58 instead of the original @ret ad- 
dress. As a result, the gadget is executed. 

6.2 Meta-gadget implementation 

This section describes the implementation of the two meta- 
gadgets. Note that a meta-gadget's implementation actually 
depends on the code present in a node. Two nodes config- 
ured with different code would, very likely, require different 
implementations. 

Injection meta-gadget. 

In order to inject one byte into memory we need to find 
a way to perform the operations that would be done by the 
"ideal" gadget, described in Figure |3(a)| This ideal gadget 
would load the address and the value to write from the stack 
and would use the ST instruction to perform the memory 
write. However, this gadget was not present in the program 
memory of our sensor. We therefore needed to chain several 
gadgets together to create what we refer to as the Injection 
meta-gadget. 

We first searched for a short gadget performing the store 
operation. We found, in the mote's code, a gadget, gadgets, 
that stores the value of register 18 at the address specified 
by register Z (the Z register is a 16 bit register alias for 
registers r30 and r31). To achieve our goal, we needed to 
pop the byte to inject into register rl8 and the injection 
address into registers r30 and r31. We did not find any 
gadget for this task. We therefore had to split this task 
into two gadgets. The first one, gadgetl, loads the injection 
destination address into registers r24 and r25, and loads the 
byte to inject into rl8. The second gadget, gadgets, copies 
the registers r24, r25 into registers r30, r31 using the "move 
word" instruction (movw). 

By chaining these three gadgets we implemented the meta- 
gadget which injects one byte from the stack to an address 
in data memory. 



To execute this meta-gadget, the attacker must craft a 
packet that, as a result of a buffer overflow, overwrites the 
return address with the address of gadgetl, and injects into 
the stack the injection address, the malicious byte, the ad- 
dresses of gadget2 and gadgets, and the value "0" (to reboot 
the node). The payload of the injection packet is displayed 
in Figure [2(b)] 

Reprogramming meta-gadget. 

As described in Section 15.3.21 the Reprogramming meta- 
gadget is required to copy a set of pages from data to pro- 
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gram memory. Ideally the ProgFlash. write function of the 
bootloader, that uses the SPM instruction to copy pages 
from the data to the program memory, could be used. How- 
ever, this function is inlined within the bootloader code. Its 
instructions are mixed with other instructions that, for ex- 
ample, load pages from external flash memory, check the 
integrity of the pages and so on. As a result, this function 
cannot be called independently. 

We therefore built a meta-gadget that uses selected gad- 
gets belonging to the bootloader. The implementation of 
this meta-gadget is partially shown in Figure [4] Due to the 
size of each gadget we only display the instructions that are 
important for the understanding of the meta-gadget. We 
assume in the following description that a fake stack was in- 
jected at the address ADDRfsp of data memory and that 
the size of the malware to be injected is smaller than one 
page. If the malware is larger than one page, this meta- 
gadget has to be executed several times. 

The details of what this fake stack contains and how it is 
injected in the data memory will be covered in Section T6, 3 1 

Our Reprogramming meta-gadget is composed of three 
gadgets. The first gadget, gadgetl, loads the address of the 
fake stack pointer (FSP) in r28 and r29 from the current 
stack. It then executes some instructions, that are not use- 
ful for our purpose, and calls the second gadget, gadgets. 
Gadget2 first sets the stack pointer to the address of the 
fake stack. This is achieved by setting the stack pointer (IO 
registers 0x3d and 0x3e) with the value of registers r28 and 
r29 (previously loaded with the FSP address). From then 
on, the fake stack is used. Gadgets then loads the Frame 
Pointer (FP) into r28 and 29, and the destination address of 
the malware in program memory, DESTm, into rl4, rl5, rl6 
and rl7. It then sets registers r6, r7, r8, r9 to zero (in order 
to exit a loop in which this code is embedded) and jumps 
to the third gadget. Gadgets is the gadget that performs 
the copy of a page from data to program memory. It loads 
the destination address, DESTm, into r30, r31 and loads 
the registers rl4, rl5 and rl6 into the register located at ad- 
dress 0x005B. It then erases one page at address DESTm, 
copies the malware into a hardware temporary buffer, before 
flashing it at address DESTm- This gadget finally returns 
either to the address of the newly installed malware (and 
therefore executes it) or to the address (the sensor then 
reboots). 

Automating the meta-gadget implementation. 

The actual implementation of a given meta-gadget de- 
pends on the code that is present in the sensor. For example, 
if the source code, the compiler version, or the compiler flags 
change, the generated binary might be very different. As a 
result, the gadgets might be located in different addresses or 



uint8-t payload [ 

0x3d, 0xf9 
FSP_H, FSP_L 
0x00,0x00,0x00, 
0xa9,0xfb 



= { 

// 

// Address of gadgetl 
// Fake Stack Pointer 
// padding to rl7,rl5,rl4 
// Address of Gadget 2 



/ / once Gadget 2 is executed the fake stack is used 

}; 



Figure 4: Reprogramming meta-gadget. The greyed 
area displays the fake stack. 



Figure 5: Payload of the Reprogramming packet. 
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Figure 6: Length of the shortest payload found 
by our automated tool to implement the Injection 
meta-gadget. 



might not be present at all. In order to facilitate the imple- 
mentation of meta-gadgets, we built a static binary analyzer 
based on the Avrora 28 simulator. It starts by collecting all 
the available gadgets present in the binary code. It then uses 
various strategies to obtain different chains of gadgets that 
implement the desired meta-gadget. The analyzer outputs 
the payload corresponding to each implementation. 

The quality of a meta-gadget does not depend on the num- 
ber of instructions it contains nor on the number of gadgets 
used. The most important criteria is the payload size i.e. 
the number of bytes that need to be pushed into the stack. 
In fact, the larger the payload the lower the chance of being 
able to exploit it. There are actually two factors that impact 
the success of a gadget chain. 

• The depth of the stack: if the memory space between 
the beginning of the exploited buffer in the stack and 
the end of the physical memory (i.e. address 0a;1100) is 
smaller than the size of the malicious packet payload, 
the injection cannot obviously take place. 

• Maximum packet length: since TinyOS maximum pa- 
cket length is set, by default, to 28 bytes, it is impos- 
sible to inject a payload larger than 28 bytes. Gadgets 
that require payload larger than 28 bytes cannot be 
invoked. 

Figure |6]shows the length of Injection meta-gadget, found 
by the automated tool, for different test and demonstration 
applications provided by TinyOS 2.0.2. TinyPEDS is an 
application developed for the European project Ubisec&Sens 

In our experiments, we used a modified version of the Ra- 
dioCountToLeds application 3 . Our analyser found three dif- 
ferent implementations for the Injection meta-gadget. These 
implementations use packets of respective size 17, 21 and 27 
bytes. We chose the implementation with the 17-byte pay- 
load, which we were able to reduce to 15 bytes with some 
manual optimizations. 

The Reprogramming meta-gadget depends only on the 
bootloader code. It is therefore independent of the appli- 
cation loaded in the sensor. The meta-gadget presented in 
figure U can therefore be used with any application as long 
as the same bootloader is used. 



6.3 Building and injecting the fake stack 

As explained in Section ^. 3. 21 our attack requires to inject 
a fake stack into the sensor data memory. We detail the 
structure of the fake stack that we used in our example and 
explain how it was injected into the data memory. 

Building the fake stack. 

The fake stack is used by the Reprogramming meta-gadget. 
As shown by Figure f?] it must contain, among other things, 
the address of the fake frame pointer, the destination address 
of the malware in program memory (DESTm), 4 zeros, and 
again the address DESTm (to execute the malware when 
the Reprogramming meta-gadget returns). The complete 
structure of the fake stack is displayed in Figure [7] The size 
of this fake stack is 305 bytes, out of which only 16 bytes 
and the malware binary code, of size sizeM, need to be ini- 
tialized. In our experiment, our goal was to inject the fake 
stack at address 0x400 and flash the malware destination at 
address 0x8000. 

Injecting the Fake Stack. 

Once the fake stack is designed it must be injected at ad- 
dress FSP = 0a;400 of data memory. The memory area 
around this address is unused and not initialized nor modi- 
fied when the sensor reboots. It therefore provides a space 
where bytes can be stored persistently across reboots. 

Since the packet size that a sensor can process is lim- 
ited, we needed to inject it byte-by-byte as described in Sec- 
tion ^. 3. 2l The main idea is to split the fake stack into pieces 
of one byte and inject each of them independently using the 
Injection meta-gadget described in Section [6.21 

Each byte Bi is injected at address FSP+i by sending the 
specially-crafted packet displayed in Figure 2(b) When the 



The RadioCountToLeds has been modified in order to in- 
troduce a buffer overflow vulnerability. 



packet is received it overwrites the return address with the 
address of the Injection meta-gadget (i.e. address 0x56b0). 
The Injection meta-gadget is then executed and copies byte 
Bi into the address FSP + i. When the meta-gadget returns 
it reboots the sensor. The whole fake stack is injected by 
sending 16 + sizeu packets, where sizeu is the size of the 
malware. 

6.4 Flashing the malware into program 
memory 

Once the fake stack is injected in the data memory, the 
malware needs to be copied in flash memory. As explained 
previously, this can be achieved using the Reprogramming 
meta-gadget described in Section T6.2I This reprogramming 
task can be triggered by a small specially-crafted packet that 
overwrites the saved return address of the function with the 
address of the Reprogramming meta-gadget. This packet 
also needs to inject into the stack the address of the fake 
stack and the address of the Gadget2 of the Reprogramming 
meta-gadget. The payload of the reprogramming packet is 
shown in Figure [5] At the reception of this packet, the tar- 
get sensor executes the Reprogramming meta-gadget. The 
malware, that is part of the fake stack, is then flashed into 
the sensor program memory. When the meta-gadget termi- 
nates it returns to the address of the malware, which is then 
executed. 

6.5 Finalizing the malware installation 

Once the malware is injected in the program memory it 
must eventually be executed. If the malware is installed at 



address it will be executed at each reboot. However, in 
this case, the original application would not work anymore 
and the infection would easily be noticeable. This is often 
not desirable. If the malware is installed in a free area of 
program memory, it can be activated by a buffer overflow 
exploit. This option can be used by the attacker to activate 



Figure 7: Structure used to build the fake stack. 
The total size is 305 bytes out of which up to 
256 bytes are used for the malware, 16 for the 
meta-gadget parameters. The remaining bytes are 
padding, that do not need to be injected. 



the malware when needed. 

This approach has at least two advantages: 

• The application will run normally, thereby reducing 
chance of detection. 

• The malware can use some of the existing functions of 
the application. This reduces the size of the code to 
inject. 

If the malware needs to be executed periodically or upon 
the execution of an internal event it can modify the sen- 
sor application in order to insert a hook. This hook can 
be installed in a function called by a timer. The malware 
will be executed each time the timer fires. This operation 
needs to modify the local code (in order to add the hook in 
the function). The same fake stack technique presented in 
Section 16.31 is used to locally reprogram the page with the 
modified code that contains the hook. The only difference 
is that, instead of loading the malicious code into the fake 
stack, the attacker loads the page containing the function to 
modify, adds the hook in it, and calls the Reprogramming 
meta-gadget. 

Note that once the malware is installed it should patch the 
exploited vulnerability (in the reception function) to prevent 
over-infection. 

6.6 Turning the malware into a worm 

The previous section has explained how to remotely inject 
a malware into a sensor node. It was assumed that this 
injection was achieved by an attacker. However the injected 
malware can self-propagate, i.e. be converted into a worm. 

The main idea is that once the malware is installed it per- 
forms the attack described in Section|S]to all of its neighbors. 
It builds a fake stack that contains its own code and injects 
it byte-by-byte into its neighbors as explained previously. 
The main difference is that the injected code must not only 
contain the malware but also the self-propagating code, i.e. 
the code that builds the fake stack and sends the specially- 
crafted packets. The injected code is likely to be larger. The 
main limitation of the injection technique presented in Sec- 
tion [6] is that it can only be used to inject one page (i.e. 
256 bytes) of code. If the malware is larger than one page 
it needs to be split it into pieces of 256 bytes which should 
be injected separately. We were able to implement, in our 
experiments, a self-propagating worm that contains all this 
functionality in about 1 KByte. 

Furthermore, because of the packet size limitation and 
the overhead introduced by the byte-injection gadget, only 
one byte of the fake stack can be injected per packet. This 
results in the transmission of many malicious packets. One 
alternative would be to inject an optimal gadget and then 
use it to inject the fake stack several bytes at a time. Since 
this gadget would be optimized it would have less overhead 
and more bytes would be available to inject useful data. This 
technique could reduce the number of required packets by a 
factor of 10 to 20. 

7. POSSIBLE COUNTER-MEASURES 

Our attack combines different techniques in order to achieve 
its goal (code injection) . It first uses a software vulnerability 
in order to perform a buffer overflow that smashes the stack. 
It then injects data, via the execution of gadgets, into the 
program memory that is persistent across reboots. 



typedef struct { 
// To be used by bottom half of gadget 2 
/ / the Frame pointer value 16 bits 
uint8-t load_r29; 
uint8-t load_r28; 

// 4 bytes loaded with the address in program 

/ / memory encoded as a uint32_t 

uint8-t load_rl7; 

uint8-t load_rl6; 

uint8-t load_rl5; 

uint8-t load_rl4; 

// 4 padding values 

uint8-t load_rl3; 

uint8-t load_rl2; 

uint8-t load_rll; 

uint8-t load_rlO; 

/ / Number of pages to write as a uint32_t 

/ / must be set to 0, in order to exit loop 

uint8-t load_r9; 

uint8-t load_r8; 

uint8-t load_r7; 

uint8-t load_r6; 

// 4 padding bytes 

uint8-t load_r5; 

uint8-t load_r4; 

uint8-t load_r3; 

uint8-t load_r2; 

/ / address of gadget 3 

uintl6_t retAddr_execFunction; 

/ / bootloader's fake function frame starts here, 

/ / frame pointer must points here 

// 8 padding bytes 

uintl6_t wordBuf; 

uintl6_t verify _image_addr; 

uintl6_t crcTmp; 

uintl6_t intAddr; 

/ / buffer to data page to write to memory 

uint8-t malware_buff [256] ; 

/ / pointer to malware_buff 

uintl6_t bufF_p; 

// 18 padding bytes 

uint8-t r29; 

umtSJ, r28; 

uint&J, rl7; 

uintS-t rl6; 

uint8-t rl5; 

uint8-t rl4; 

uint8-t rl3; 

UintS-t rl2; 

uint8-t rllj 

uint8-t rlO; 

uint8-t r9; 

uint8-t r8; 

uint8-t r7; 

uint8-t r6; 

uint8-t r5; 

uint8-t r4; 

uint8-t r3; 

uint8-t r2; 

/ / set to the address of the malware or to reboot 
uintl6_t retAddr; 
} fake_stack_t; 



/ / function declaration with proper attributes 
void cleanup_memory (void) 

attribute ((naked)) 

_attribute_ ((section (".init8"))) 

@spontaneous() @C(); 

/ / bss_end symbol is provided by the linker 

extern volatile void* bss_end; 

void cleanup_memory( void){ 

uint8_t *dest = & bss_end; 

uintl6_t count=RAMEND (uintl6_t)&_bss_end; 
while (count — ) *dest++ = 0; 

} 



Figure 8: A memory cleanup procedure for TinyOS. 
The attribute keyword indicates that this function 
should be called during the system initialisation. 



might store in memory a buffer of data to be sent to the 
sink). If such a feature exists it could be exploited in order 
to store the fake stack without having to use the Injection 
meta-gadget. In this case, only the Reprogramming meta- 
gadget would be needed and the presented defense would be 
ineffective. 

Gadget execution protection. 

ASLR (Address Space Layout Randomization) 26 is a 
solution that randomizes the binary code location in mem- 
ory in order to protect against return-into-libc attacks. Since 
sensor nodes usually contain only one monolithic program in 
memory and the memory space is very small, ASLR would 
not be effective. [16] proposes to improve ASLR by ran- 
domising the binary code itself. This scheme would be adapt- 
able to wireless sensors. However, since a sensor's address 
space is very limited it would still be vulnerable to brute 
force attacks 1241 . 



Any solutions that could prevent or complicate any of 
these operations could be useful to mitigate our attack. How- 
ever, as we will see, all existing solutions have limitations. 



Software vulnerability Protection. 

Safe TinyOS [fr provides protection against buffer over- 
flow. Safe TinyOS adds new keywords to the language that 
give the programmer the ability to specify the length of an 
array. This information is used by the compiler to enforce 
memory boundary checks. This solution is useful in prevent- 
ing some errors. However, since the code still needs to be 
manually instrumented, human errors are possible and this 
solution is therefore not foolproof. Furthermore, software 
vulnerabilities other than buffer overflows can be exploited 
to gain control of the stack. 

Stack-smashing protection. 

Stack protections, such as random canaries, are widely 
used to secure operating systems [6]. They are usually im- 
plemented in the compiler with operating system support. 
These solutions prevent return address overwriting. How- 
ever, the implementation on a sensor of such techniques 
is challenging because of their hardware and software con- 
straints. No implementation currently exists for AVR mi- 
crocontrollers. 

Data injection protection. 

A simple solution to protect against our data injection 
across reboots is to re-initialize the whole data memory each 
time a node reboots. This could be performed by a simple 
piece of code as the one shown in the Figure [8] Cleaning 
up the memory would prevent storing data across reboots 
for future use. This solution comes with a slight overhead. 
Furthermore it does not stop attacks which are not relying 
on reboots to restore clean state of the sensor as proposed 
in [12]. It is likely that our proposed attack can use similar 
state restoration mechanisms. In this case such a counter- 
measure would have no effect. 

Furthermore our attack is quite generic and does not make 
any assumptions about the exploited applications. However, 
it is plausible that some applications do actually store in 
memory data for their own usage (for example an application 



8. CONCLUSIONS AND FUTURE WORK 

This paper describes how an attacker can take control of a 
wireless sensor network. This attack can be used to silently 
eavesdrop on the data that is being sent by a sensor, to 
modify its configuration, or to turn a network into a botnet. 

The main contribution of our work is to prove the feasibil- 
ity of permanent code injection into Harvard architecture- 
based sensors. Our attack combines several techniques, such 
as fake frame injection and return-oriented programming, in 
order to overcome all the barriers resulting from sensor's ar- 
chitecture and hardware. We also describe how to transform 
our attack into a worm, i.e., how to make the injected code 
self-replicating. 

Even though packet authentication, and cryptography in 
general, can make code injection more difficult, it does not 
prevent it completely. If the exploited vulnerability is lo- 
cated before the authentication phase, the attack can pro- 
ceed simply as described in this paper. Otherwise, the at- 
tacker has to corrupt one of the network nodes and use its 
keys to propagate the malware to its neighbors. Once the 
neighbors are infected they will infect their own neighbors. 
After few rounds the whole network will be compromised. 

Future work consists of evaluating how the worm prop- 
agates on a large scale deployment. We are, for example, 
interested in evaluating the potential damage when infec- 
tion packets are lost, as this could lead to the injection of 
an incomplete image of the malware. Future work will also 
explore code injection optimizations and efficient counter- 
measures. 
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